…s API (#48226)

## Summary
- `vercel/wait-for-deployment-action` in
[docs-e2e.yml](.github/workflows/docs-e2e.yml) polls GitHub's
Deployments API for a `Preview – docs` deployment, but Vercel's GitHub
App has not written a GitHub Deployment object repo-wide since
2026-02-17 (broken app auth). The step times out after 900s on every PR
that touches `apps/docs`, even though the preview build itself succeeds
(`Vercel – docs` commit status is green).
- Replace the wait step with a custom poll of the `Vercel – docs` commit
status (which Vercel keeps posting correctly), then resolve the actual
preview URL via Vercel's own deployments API (`GET
/v13/deployments/{id}`) using the deployment ID embedded in the commit
status's `target_url`, reusing the existing `VERCEL_TOKEN` /
`VERCEL_TEAM_ID` secrets.
- Drops the now-unused `deployments: read` permission.

## Context
Reported in Slack:
https://supabase.slack.com/archives/C023E4L60R3/p1784721725606599?thread_ts=1784658589.182079&cid=C023E4L60R3
(surfaced by [#48178](#48178)
failing on this step — [run
29916797889](https://github.com/supabase/supabase/actions/runs/29916797889?pr=48178)).
Agreed workaround from that thread: swap the wait step to poll the
`Vercel – docs` commit status instead of the Deployments API.

## Test plan
- [ ] Confirm this workflow run (triggered by this PR since it edits
`apps/docs/**`... actually this PR only touches the workflow file, so
verify via `workflow_dispatch` or a follow-up PR touching
`apps/docs/**`) passes the "Wait for Vercel docs preview" step and
resolves a working `deployment-url`
- [ ] Confirm downstream Playwright E2E run against the resolved preview
URL succeeds
- [ ] Confirm the step still fails cleanly (clear error, no silent hang)
if the Vercel deployment itself fails

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Improved documentation preview deployment handling in end-to-end
tests.
* Replaced the preview wait logic with more reliable polling for the
relevant commit status, including clear success/failure/error and
timeout behavior.
  * Resolve the correct documentation preview URL before tests proceed.
* **Chores**
* Tightened permissions for the documentation E2E workflow to use only
the required access scopes.
* Streamlined job setup steps so Node/Pnpm preparation runs earlier in
the workflow.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…48264)

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Bug fix — the [events index](https://supabase.com/events) was featuring
the TRAE webinar in its marquee days after the event happened, instead
of the next genuinely upcoming event (the Dublin meetup), and counting
it toward the "Webinar" filter chip alongside actually-upcoming
webinars.

## What is the current behavior?

`getMdxEvents()` in `lib/events.ts` only excludes past events by
comparing dates against the start of today in UTC. It doesn't check
`onDemand` at all. The TRAE event's timestamp
(`2026-07-22T19:00:00.000-07:00`) converts to `2026-07-23T02:00:00Z`,
which is still "today or later" by that UTC cutoff — so even though the
event already happened and flipped to `onDemand: true`, it kept getting
returned as an "upcoming" event. Since the events marquee
(`featuredEvent`) just picks the earliest-dated event from that pool,
TRAE kept winning over the actually-upcoming Dublin meetup, and it kept
counting toward the "Webinar" filter chip.

## What is the new behavior?

`getMdxEvents()` now excludes any event with `onDemand: true` outright,
regardless of how its date converts across timezones — on-demand events
belong solely in the on-demand bucket (`getOnDemandMdxEvents`), not the
upcoming/marquee pool. Verified locally: the "Webinar" filter chip count
on `/events` drops to 0 with this in place (previously counted TRAE),
while the TRAE event's card in the on-demand list still correctly shows
its "Webinar" tag and "Supabase Live" line, matching the other on-demand
webinars (Perplexity, Datadog) — only its bucket assignment changed, not
its labeling.

## Additional context

Couldn't verify the marquee itself locally since the Luma events API
returns a 500 in local dev (missing credentials, pre-existing/unrelated
to this change). Confirmed independently via the production Luma API
that the Dublin meetup (`2026-07-28T17:00:00Z`) is genuinely the next
chronological event, so it will naturally take over the marquee once
this ships — no hardcoding needed.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
  * On-demand events are no longer shown in the upcoming events list.
* Upcoming events continue to be filtered by their relevant date, while
on-demand event listings remain unchanged.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

- The failed-upgrade banner reflects the API's last-known upgrade
status, which stays "Failed" indefinitely even after a project is
restored, so it never went away
- A hard refresh didn't help, since this isn't client-cached state
- Adds a dismiss action, scoped to the attempt's `initiated_at` so a
future failed upgrade still shows the banner

Fixes FE-3964

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
  * Added a dismiss control to project upgrade failure notifications.
* Dismissed notifications remain hidden for the current project until a
new upgrade failure occurs.
  * Contact support remains available alongside the dismiss option.

* **Bug Fixes**
* Improved upgrade failure banner behavior by persisting dismissal state
across page visits.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->